I don't know what it would imply but if we replace std.builtin.AddressSpace by a tagged union we may be able to achieve a syntax like this, which would be easier to read and write imo (or maybe I'm completely wrong)

extern var frag_color: @Vector(4, f32) addrspace(.output = .{ .location = 0 });
extern const ubo: UBO addrspace(.uniform = .{ .set = 0, .binding = 0 });

It would even semantically fix the issue where you can setup a set/binding on an input/output variable like so

const out = @extern(*addrspace(.output) Out, .{
    .name = "out",
    .decoration = .{
        .descriptor = .{ .set = 0, .binding = 0 },
    },
});

Address space and descriptor/binding location are completely different concepts. Moving them into address space would result unintended inequality. I think @extern is the perfect spot.

Address space and descriptor/binding location are completely different concepts. Moving them into address space would result unintended inequality. I think @extern is the perfect spot.

Conceptually yes, but a core tenet of Zig's design is that readability is favored over writability and this is rough to read in a shader. Weren't there discussions about adding more SPIR-V builtins like @workGroupSize ? @location, @set and @binding would be the best solution.

I do agree with @Kbz-8. I believe that adding specific SPIR-V builtin would be beneficial here. Though I think this pr is a great improvement

I thinks a discussion should be done where everyone sits and speaks about how Zig shaders should be written instead of waiting for potential PRs.

But this is what @extern is for — bindings to external things. We can also add a wrapper to std.gpu:

pub fn descriptor(T: type, comptime binding: u32, comptime set: u32) T {
    return @extern(T, .{
        .name = "unused",
        .decoration = .{
            .descriptor = .{ .binding = binding, .set = set },
        }
    });
}

const my_image = descriptor(*const Image, 0, 0);

though the unused name is a little annoying.

I think there are very many potential SPIR-V builtins and I don’t know if Zig wants to go down that rabbit hole. We should be reducing the number of builtins imo, not increasing it.

The nice thing about just using @extern is this makes CPU Zig experience transferable to GPU Zig experience. If I’ve only ever read CPU Zig code and I see @extern on the GPU, I get a pretty good idea of what it’s doing, which doesn’t happen if it’s using some new builtin.

(reposing on correct account)

I thinks a discussion should be done where everyone sits and speaks about how Zig shaders should be written instead of waiting for potential PRs.

Feel free to submit a proposal. :)